NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/13428

Internet Message Format | 1996-08-05 | 8.4 KB

Path: seagoon.newcastle.edu.au!usenet
From: [e-mail] (Richard Mazzaferri)
Newsgroups: comp.lang.c++
Subject: Re: C++ vs Delphi 2.0
Date: Tue, 26 Mar 1996 04:12:37 GMT
Organization: Newcastle University
Message-ID: <[e-mail]>
References: <[e-mail]> <4hmop6$[e-mail]> <4ims71$[e-mail]> <[e-mail]> <4j2u9o$[e-mail]>
NNTP-Posting-Host: tesla.newcastle.edu.au

"Thaddeus L. Olczyk" <[e-mail]> wrote:

> [e-mail] (Richard Mazzaferri) wrote:

> More importantly you can only pass functions and variables to a dll.
> The class structure of your code will be completely lost.

Absolutely - this was meant to be implicit in my statement that you have to
use a "straight C interface" - you can't pass C++ classes across the
boundary.

> I have argued in the past and continue to argue now that it is a misnomer
> to call Delphi OO. It partial emulates the C++/Eiffel model of static
> typing, but misses severely by what it keeps out. It partially emulates
> the Smalltalk model of dynamic typing, but in a convoluted way.

Could you expound on this - perhaps in e-mail if you've done this before
publicly?  I'm intellectually interested in the important differences you
see between the models.  The debate about what does and what doesn't
constitute "true OO" tends to take on religious overtones very quickly, so
I'm not going to waste time discussing *that* particular point.  On the
other hand, I have to state that the commercial realities are (IMHO) that
Delphi is the best choice for many applications (despite any real or
perceived intellectual shortcomings) so your discussion is unlikely to
change my viewpoint there :-)

> >The biggest omissions are multiple inheritance (which can generally be
> >faked with a bit of work) and templates (no workaround :-(.  Some of the

> Many times a lot of work or virtually impossible.

Most of the time, multiple inheritance is not *strictly* necessary
(although I have one case where it is), and the workaround via delegation
takes a bit of time - you have to declare functions that would otherwise be
inherited, and in their implementation call the delegated object instead.
While this is some work that could be avoided by implementing multiple
inheritance, it is not virtually impossible - it just leads to a different
sort of class hierarchy design.  I would prefer to have real multiple
inheritance, but in the real world projects I've done so far, it hasn't
been sorely missed.  Now, what I *really* miss is templates.

> >big wins are properties and really good exception handling and RTTI.  I
> >also find that I generate far fewer bugs in Delphi than I did in C++,
> >probably to do with the type checking.

> Or more to do with the fact that you probably wrote C code in C++.

I resent that :-)

I did *not* and do not write C code in C++ - ask me for sample code or
references :-)  I recently added features to a public domain utility
program written in straight C, and I found it a very restrictive exercise.

> Properties -- A feature of any dll/vbx type architecture. Affects most
> programming very little ( at the cost of some overhead too ).

Perhaps it is - but I believe that most DLL/VBX properties are implemented
as a set of longint/pointer values keyed on a longint property identifier,
whereas Delphi's properties are typed class members just like data or
function members.  They are inherited, and can be public/private/protected
or published, and effectively hide the implementation.
    The use of object member function pointers (generally as properties) is
much more useful than those in C++ (paradoxically) because C++'s member
function pointers are strongly typed.  This makes the use of member
function pointers in C++ as event handlers for GUI functions a lot more
difficult, because you can only point to a member function of an object of
the class declaring the function.

> Exception handling -- a feature of both Delphi and C++ and is used the
> same way in both. Except for one exception, Delphi's model of
> explicitly constructing and destructing objects means that a lot more
> effort is expended to make sure resources are freed ( nested finally
> blocks) .

Internal to a class, the resource freeing problem is identical to that in
C++ - generally, any member you allocate in the class (typically in the
constructor), you free in the class (typically in the destructor).  Given
that *most* to *all* of the code in a Delphi program is inside a class,
this gives no extra work.  Where the "try ... finally" resource protection
is required is for what would be automatic variables in C++, and there is
generally no need for *nested* "try ... finally" blocks.  Consider:

procedure TSomeClass.SomeFn;
var
    o1 : TObject1;
    o2 : TObject2;
begin
    try
        { Both o1 and o2 are nil at this point. }
        o1 := TObject1.Create;
        o2 := TObject2.Create;
        { Do something with o1/o2 }
    finally
        { Freeing a nil object has no effect. }
        o2.Free;
        o1.Free;
    end;
end;

I can type a try ... finally block in very little time, so I don't consider
this "a lot more effort", but YMMV.  Many people would consider that the
explicit construction/destruction is clearer than the implicit model in
C++, but I don't really care either way.

> As for RTTI, it is similar to C++ RTTI , but I believe the
> standards committee considers it a nessecsary evil, because programmers
> can do it themselves quite easily. It is a bad practice
> because it hurts strong type checking. Unfortunately in Delphi
> you have to revert to it often because of the poor object model.

I find that there are three main reasons to revert to RTTI.

The first is the lack of templates, leading to generic container classes
(as if they are parameterised on TObject rather than the class of choice).


The second is the way the Windows GUI works: messages are sent to and from
all sorts of GUI "objects" (and even that rarely requires RTTI).  This is
reflected in the VCL design where GUI event handlers are by default a
member function of the form - something that is difficult to accomplish in
C++, because it tends to require that the form class declare a virtual
event handler function for *every* type of event that it wants to handle.

The third use of RTTI I find is for heterogeneous collections.
Traditionally in C++ this would be handled by factoring out some sort of
base class with appropriate virtual functions and parameterising the
collection class on this base class.  There are situations where this is
either not appropriate, or requires RTTI anyway, no matter which language
you choose.

Now, apart from these reasons, I haven't had occasion to use RTTI.  Do any
of these reasons stem from the "poor object model"?  If not, could you give
me some examples that do so that I understand what you are referring to?

> I would say that Delphi is a tool usefull for single programmers, or
> for a small team working on a small (less then three month long ) project.

Hmm, small team, four months and counting... YMMV.

As a commercial choice, I find that for my current projects, Delphi is
superior to C++.  I can produce a lot more personally (and I'm no slouch in
C++), AND I can bring new programmers into the team and have them producing
*good* code a lot more quickly in Delphi than with C++.  It seems to be a
lot easier to produce bad code in C++, and consequently a lot harder to
find good software engineers.  Again, YMMV.

This is not to say that there are language features that are better
implemented (or implemented at all :-) in C++ (or Eiffel, or Smalltalk...).
However, the bottom line is either the purity of the intellectual OO model,
or sustained earning power.  A different bottom line will lead to different
conclusion.

> >I don't understand why it "..discourages one from using code...".

> One of the major selling points of Delphi I hear from most Delphi
> programmers is "isn't it great I can write this application with
> virtually no code".

I think you'll find that constructing most of the GUI - including a
significant amount of database manipulation - can be accomplished with very
little code, which leads programmers to make these statements.  This does
not suggest to me that Delphi discourages the use of code.  In practice,
the guts of most real applications requires decent amounts of code.

Have fun,
    Mazz.

PS Looking at the subject line: I haven't seen Delphi v2.0 yet :-)
[e-mail]